前言
距离上一篇宣告 OCM 开源并提交 CNCF TOC 项目孵化申请的文章已经有一个多月了。这一个多月来 OCM 社区吸引了越来越多的关注和伙伴们的加入，OCM 自身的研发，相关领域产品和解决方案的应用也取得了快速的发展。如果你还在对云原生环境下多集群管理的技术选型犹豫不决，希望这篇文章能够答疑解惑。现在参与 OCM 社区正是时候。OCM 社区研发进展
Open Cluster Management 在七月份发布了 0.4.0 版本，新加入的主要功能包括：通过 ManagedClusterAddon API，用户可以定义管理插件说明在被管理集群上安装管理插件，而后通过管理插件实现可扩展的管理能力。例如，用户可以在中心集群上的 ManagedCluster 资源对应的命名空间中创建名为 submariner 的 ManagedClusterAddon 资源来激活被管理集群中 submariner 的安装和配置，使用 submariner 作为多集群网络连通的解决方案。集群管理插件的注册和管理如下图所示：
每个插件需要一个在中心集群上运行的控制器。这个控制器由插件的开发者开发，主要目的是告诉 OCM 这个插件在被管理集群中需要如何被安装，如何和中心集群通信以及对应的通信权限。OCM 通过这些信息负责插件在被管理集群的部署和与中心集群的通信。为了方便开发者方便的开发基于 OCM 的管理组件，OCM 0.4.0 加入了 addon-framework 的 golang 框架帮助开发者。开发者只需要实现框架透出的接口提供插件的部署和配置信息，同时框架还提供了若干帮助函数，方便开发者在 Kubernetes 平台添加资源处理逻辑。开发人员可以将 Kuberentes 自定义资源的 Operator 也实现在插件内。2、集群负载和任意资源调度的新 Placement API OCM 0.4.0 引入了一个新的 Placement API，描述如何为多集群的负载或 Kubernetes 的任意自定义资源选择部署目标的一个或多个集群。Placement 需要在一个或多个特定的 ManagedClusterSet 中选择集群，并且这些集群必须通过 ManagedClusterSetBinding 绑定到 Placement 对应命名空间内。在 OCM 0.4.0 中用户可以通过 ManagedCluster 上的标签或者 ClusterClaims 来选择集群。例如用户可以通过以下方式选择所有标签为“env=prod”的集群来分发配置信息：apiVersion: cluster.open-cluster-management.io/v1alpha1kind: Placementmetadata: name: placement1 namespace: ns1spec: predicates: - requiredClusterSelector: labelSelector: matchLabels: env: prod也可以通过以下 Placement 选择特定数目和特定 Kubernetes 版本的集群来部署应用。apiVersion: cluster.open-cluster-management.io/v1alpha1kind: Placementmetadata: name: clusters-from-specific-version namespace: ns1spec: numberOfClusters: 3 predicates: - requiredClusterSelector: claimSelector: matchExpressions: - key: kubeversion.open-cluster-management.io operator: In values: - 1.18.0 - 1.18.1
apiVersion: cluster.open-cluster-management.io/v1alpha1kind: PlacementDecisionmetadata: labels: cluster.open-cluster-management.io/placement: placement1 name: placement1-decision-1 namespace: ns1status: decisions: - clusterName: cluster1 - clusterName: cluster2 - clusterName: cluster3需要注意的是 Placement 只是根据 API 的定义选择满足要求的集群，而不关心如何分发配置和部署应用。Placement 需要和其他的应用或配置分发组件，包括应用的管理控制器，例如 ArgoCD 或者 KubeVela，共同完成应用的调度和部署。这也是 OCM “微内核”设计思想的一个体现，调度服务与应用或者资源管理服务完全解耦。在后续的开发过程中，我们在计划引入更多的调度策略，如通过集群的资源使用情况调度，taint/toleration 机制和非亲和性等。如果有新的调度策略要求，欢迎在 community 子项目提出需求。3、clusteradm命令行工具（alpha版本）clusteradm 受 kubeadm 的启发，主要的目的是简化 OCM 组件的安装和集群注册。用户可以通过运行“clusteradm init”命令在中心集群上部署 OCM 管理组件。并使用”clusteradm join”命令在被管理集群部署 OCM 本地组件，并将集群注册到中心集群。clusteradm 也在不断发展，后续会加入更多的 OCM 管理和监控子命令。OCM 社区研发计划
OCM 计划在 10 月份发布 0.5.0 版本。0.5.0 版本的开发重点主要包括对 Placement API 的进一步完善，提升用户体验以及新的网络通信子项目。进一步增强 clusteradm 的功能，主要是通过 clusteradm 部署和管理 OCM 插件的能力。通过反向隧道的方式实现对被管理集群的 Kubernetes API，运行在被管理集群的服务，甚至节点 sshd 的直接访问。让管理员或者 controller 可以直接访问到在防火墙后的被管理集群 。OCM 与其他项目合作
OCM 目前是 KubeVela 多集群管理的核心组件，用户可以通过 KubeVela 的应用交付工作流一站式的完成集群创建、集群注册，直到最后的多集群应用部署。这一技术流程满足了应用在开发、测试、生产不同阶段的一致性诉求，用户可以通过 KubeVela 一键式的创建集群环境，使得本地开发能够与生产部署采用同样的模式做验证，保证了软件交付的成功率和正确性。另一方面，KubeVela 与 OCM 一起构建了丰富的多集群多环境应用交付能力，在 OCM 提供集群调度和资源分发的基础上，用户可以通过 KubeVela 对一个应用实现不同环境的差异化配置，使得一个应用部署到不同集群环境可以拥有不同的配置属性和运维策略。OCM 也在持续和其他开源项目合作尝试通过 OCM 来增强其他项目的多集群管理能力。OCM 社区和 ArgoCD 合作推进在 ArgoCD 中使用第三方 API 来进行集群调度并通过 ArgoCD 部署应用用户可以使用 ArgoCD 的 ApplicationSet 配合 OCM 中的 Placement API 实现多集群应用的部署。OCM 社区也尝试和 Clusternet 合作 。通过 OCM 的插件管理能力可以将 clusternet 做为插件加载到 OCM 中，从而方便的同时使用 Clusternet 和其他 OCM 插件的功能。OCM 在产品和解决方案中的落地
阿里云专有云敏捷版的企业化容器平台在不同类型的用户场景下，需要管理形态各异的用户集群，负责这些集群的部署，管理服务的安装，资源规划，监控，合规，策略管理，负载分发等工作。随着功能的不断丰富，最初的自研架构遇到了扩展性，易用性，研发效率等问题。通过调研发现 OCM 的“微内核”设计不仅很好的解决了上述架构问题，而且对二次开发非常友好，研发人员可以自由选择 OCM 社区的子项目，并在选择的原子能力基础上增加不同场景的业务逻辑。当前使用和计划使用的 OCM 子项目和相关能力包括：容器平台支持管理自主创建集群，用户既有集群，边缘集群，云服务商集群。根据集群类型的不同，在被管理集群上部署的管理服务种类，部署的方式，对集群的配置等都不一样。使用 registration 和 work 子项目，容器平台可以定制集群注册的自动化流程。根据 registration-agent 收集和报告的集群属性信息，自动化注册流程可以决定部署的管理服务种类和集群配置，并通过 work-agent 部署在被管理集群内。特别的，当集群运行在防火墙之后时，容器平台会部署 proxy 服务实现 Kubernentes 和管理服务 API 的反向代理，甚至在需要时可以代理ssh协议实现技术支持人员的远程运维。
proxy 服务正在以 addon-framework 子项目支持的 OCM addon 的方式贡献给 OCM 社区，计划在 0.5.0 版本发布。正如上文中提到的，不同集群类型中部署的管理服务不尽相同。如何有序的管理这些服务，并清楚的展示被管理集群可以提供的管理能力是一个需要解决的问题。使用 addon-framework 子项目，容器平台可以为每个管理服务在中心集群实现 operator，根据管理员使用 placement 子项目创建的策略，容器平台可以通过 operator 编排服务的类型和配置，并通过 work 子项目下发到各个被管理集群。集群的管理也包括安全策略，网络策略，访问策略等的管理。这些策略通常以 Kubernetes 扩展资源的形态出现。容器平台可以直接使用 governance-policy-propagator 子项目，或者参照它实现自己的策略分发和策略执行状态的上报机制。阿里云容器服务 Kubernetes 版（Alibaba Cloud Container Service for Kubernetes，简称容器服务 ACK），提供高性能的容器应用管理服务。随着客户对 Kubernetes 容器的深入使用，以及业务的多地域全球化发展，用户创建管理多个 ACK 集群以及注册了多云集群来应对持续扩张的业务需求，同时 ACK 对大数据和 AI 作业的调度，队列和分发做了多项优化工作，越来越多的企业用户选择 ACK 运行大数据和 AI 作业。针对 ACK 的多集群／多云用户运行大数据／AI 作业，如何在众多集群中选择资源容量，污点，地域亲和性，作业优先级匹配的集群，通过运维团队人为判别选择往往耗时且容易出错，并需要经过多个团队协同。多集群大数据／AI 作业统一分发和管理成为了数据科学家／开发工程师面对的棘手问题。基于 OCM 的开放架构，ACK 作业队列控制器和多集群调度器可以很容易适配 OCM，结合 OCM 的集群注册管理，作业分发机制，实现大数据/AI 作业的多集群调度分发管理。ACK 使用 OCM 的集群注册管理机制，构建以 OCM Hub 主集群为中心的多集群运行环境，并以 Hub 主集群为统一管控入口。用户使用 Kubernetes 原生接口提交作业后，ACK 队列控制器和多集群调度器会根据作业优先级，资源用量要求，结合使用 OCM ManagedCluster API 获取子集群健康情况，资源容量，亲和性等信息，实现基于优先级的作业排队，出队，调度，为作业自动选择合适的子集群。ACK 扩展 OCM Manifestworks API 将作业分发到相应的子集群运行，并使用 OCM Proxy 插件机制获取作业在子集群上的运行状态。通过结合 OCM 和 ACK 作业队列控制器和多集群作业调度器，ACK 很好地解决了多集群环境中的大数据／AI 作业自动调度，作业分发和状态追踪等问题。
相关链接：
插件注册和生命周期的管理
https://github.com/open-cluster-management-io/enhancements/tree/main/enhancements/sig-architecture/12-addon-manager
集群负载和任意资源调度的新 Placement API https://github.com/open-cluster-management-io/enhancements/tree/main/enhancements/sig-architecture/6-placements
https://github.com/open-cluster-management-io/clusteradm clusternet 插件
https://github.com/skeeey/clusternet-addon
基于集群可分配资源的调度
https://github.com/open-cluster-management-io/enhancements/pull/16
负载的非亲和和亲和
https://github.com/open-cluster-management-io/community/issues/49
集群taint/toleration
https://github.com/open-cluster-management-io/community/issues/48
https://github.com/open-cluster-management-io/enhancements/pull/19
多集群应用部署
https://github.com/oam-dev/kubevela/tree/master/docs/examples/workflow-with-ocm
ArgoCD 部署应用
https://github.com/argoproj-labs/applicationset/pull/231
Clusternet 合作
https://github.com/clusternet/clusternet